Zmq RPC in daemon #2044

tewinget · 2017-05-24T15:49:31Z

There are things that could still be improved, but I think it's in a good state to be merged.

EDIT: separated some changes into a different PR, now this PR depends #2184.

moneromooo-monero · 2017-05-27T11:44:45Z

src/cryptonote_basic/cryptonote_basic.h

@@ -91,7 +91,7 @@ namespace cryptonote

  struct txin_gen
  {
-    size_t height;
+    uint64_t height;


This should be reverted, also the three ones below (as per my IRC explanation)

moneromooo-monero · 2017-05-27T11:48:09Z

src/cryptonote_core/blockchain.cpp

+
+uint64_t Blockchain::get_num_mature_outputs(uint64_t amount) const
+{
+  auto num_outs = m_db->get_num_outputs(amount);


As a general comment, I prefer when types aren't left to "whatever" for integer types, where size and signedness matter a lot. This should be uint64_t, but it hidden here.

moneromooo-monero · 2017-05-27T11:53:16Z

src/cryptonote_core/tx_pool.cpp

@@ -567,6 +576,15 @@ namespace cryptonote
    //transaction is ok.
    return true;
  }
+
+  //---------------------------------------------------------------------------------
+    void tx_memory_pool::get_transactions_and_key_images(transactions_container& txs, key_images_container& key_images) const


indent got wonky here

moneromooo-monero · 2017-05-27T11:54:18Z

src/cryptonote_core/tx_pool.cpp

@@ -514,6 +514,15 @@ namespace cryptonote
    return m_spent_key_images.end() != m_spent_key_images.find(key_im);
  }
  //---------------------------------------------------------------------------------
+  void tx_memory_pool::have_key_images_as_spent(const std::vector<crypto::key_image>& key_images, std::vector<bool>& spent) const
+  {
+    CRITICAL_REGION_LOCAL(m_transactions_lock);


If this gets merged after the txpool patch, the blockchain lock needs taking here after the transactions lock

moneromooo-monero · 2017-05-27T11:54:33Z

src/cryptonote_core/tx_pool.cpp

+    void tx_memory_pool::get_transactions_and_key_images(transactions_container& txs, key_images_container& key_images) const
+  {
+    // need to lock so the transactions container doesn't change during copy
+    CRITICAL_REGION_LOCAL(m_transactions_lock);


If this gets merged after the txpool patch, the blockchain lock needs taking here after the transactions lock

moneromooo-monero · 2017-05-27T13:01:38Z

src/rpc/zmq_server.cpp

+    zmq::socket_t* socket = new zmq::socket_t(context, ZMQ_REP);
+
+    std::string bind_address = addr_prefix + address + std::string(":") + port;
+    socket->bind(bind_address.c_str());


Error checking ?

moneromooo-monero · 2017-05-27T13:02:27Z

src/rpc/zmq_server.cpp

+    if (new_socket)
+    {
+      delete new_socket;
+    }


This deletes on exception, but the previous function does not. Different semantics, or leak ?

moneromooo-monero · 2017-05-27T13:02:44Z

src/rpc/zmq_server.cpp

+    return false;
+  }
+  return true;
+}


Those two functions should be merged, they're pretty much the same.

moneromooo-monero · 2017-05-27T13:03:54Z

src/rpc/zmq_server.cpp

+  running = false;
+
+  return;
+}


That looks racy.

moneromooo-monero · 2017-05-27T13:05:25Z

src/serialization/json_object.cpp

+  }
+
+  i = (uint8_t)( val.GetUint() & 0xFF);
+}


I'd error out on bad range, instead of losing bits. Less scope for confusion, exploits, etc.

fluffypony · 2017-05-30T19:25:26Z

Needs rebasing, and check review comments

peronero · 2017-06-10T14:25:53Z

I hate to be that guy, but what's going on here? Back-and-forth turnaround is seemingly on weeks-to-months timeframes and @tewinget seldom attends the dev meetings, despite this being under the FFS. The funding proposal is sparse in detail but this work seems to be more than 6 months late by the original estimate.

This is a pretty significant component - as I understand it, a hard dependency for functionality like block- and wallet- notify and in turn a roadblock for ecosystem infrastructure development.

I would recommend either:

1 - getting committment from tewinget to complete this work on some sort of firm timetable
2 - having someone familiar with the codebase (like @moneromooo-monero ) estimate the remaining effort and reallocating the difference from the 1000XMR left to another developer

There is, ostensibly, a dev meeting tomorrow where this can be discussed.

tewinget · 2017-06-10T19:40:50Z

"I hate to be that guy, but" You shouldn't, because you're right. I've been shit as far as communication goes. There are reasons, but they're certainly not excuses, so I won't bother listing them. "1 - getting committment from tewinget to complete this work on some sort of firm timetable" That's something I should have done from day one, to be quite honest. It's June 10th, so that's what...20 days left in the month? Alright, I'll commit to having the daemon server / wallet client parts of zmq mergeable (with all major concerns addressed) by the end of the month, as well as at least a prototype (read: usable but perhaps not polished) for {block,tx}notify. As for the dev meetings: it's no excuse, but I legit just forget. I'm adding it to my calendar with a reminder the day before right after I send this. (You'd think I'd have done so a while ago...)

…

On Sat, Jun 10, 2017 at 10:25 AM, peronero ***@***.***> wrote: I hate to be that guy, but what's going on here? Back-and-forth turnaround is seemingly on weeks-to-months timeframes and @tewinget <https://github.com/tewinget> tewinget sparsely attends the dev meetings, despite this work being under the FFS. The funding proposal is lacking in detail and requirements but this work seems to be more than 6 months late by the original estimate. This is a pretty significant component - as I understand it, a hard dependency for functionality like block- and wallet- notify and in turn a roadblock for ecosystem infrastructure development. I would recommend either: 1 - getting committment from tewinget to complete this work on some sort of firm timetable 2 - having someone familiar with the codebase (like @moneromooo-monero <https://github.com/moneromooo-monero> ) estimate the remaining effort and reallocating the difference from the funds yet to another developer (there is 1000XMR remaining which should be enough) There is, ostensibly, a dev meeting tomorrow where the 0MQ work can be discussed. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5jr0SOyhoarXErEQXmmWTLcnRRjaks5sCqdzgaJpZM4NlTvc> .

-- Thomas Winget Computer Engineering Purdue University '12

dternyak · 2017-06-10T20:39:44Z

@tewinget Thank you for your responsible and courteous reply, as well as the commitment to have ZMQ ready by the end of the month.

I have been following ZMQ's development for a while now, and I, among many others, are excited that it's getting close 👍

ghost · 2017-06-10T20:53:04Z

@tewinget Thanks

peronero · 2017-06-11T15:29:27Z

Thanks @tewinget.

If I could make one more recommendation - and I really hate to be that guy again - but you might find it useful to break down the work into smaller milestones instead of aiming to deliver the whole thing 3 weeks from now.

Cheers

tewinget · 2017-06-11T15:41:14Z

I agree, and am already going to spend today and tomorrow doing that as I work.

…

On Sun, Jun 11, 2017 at 11:29 AM, peronero ***@***.***> wrote: Thanks @tewinget <https://github.com/tewinget>. If I could make one more recommendation - and I really hate to be that guy again - but you might find it useful to break down the work into smaller milestones instead of aiming to deliver the whole thing 3 weeks from now. Cheers — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5ttu0JCebP0FIYCIL5dF9CFItBpaks5sDAfZgaJpZM4NlTvc> .

-- Thomas Winget Computer Engineering Purdue University '12

tewinget · 2017-06-25T17:33:53Z

Apart from squashing any compiler bugs on various platforms and choosing a version of libzmq to bring in-source and doing that (assuming we still want to do so), I believe all of the comments here have been addressed. Testing is a bit tedious until I've got the client side of things back in good shape -- look for that in the next two days. If you're dying to test things sooner than that, PM me on IRC and I'll get back to you as soon as I see the message.

peronero · 2017-07-01T00:59:20Z

OK, so I believe we're in a spot where these components can be reviewed and iterated upon if need be, and the notify stuff is impending separately.

Thanks @tewinget

moneromooo-monero · 2017-07-08T12:25:12Z

src/rpc/daemon_handler.cpp

+          res.blocks.clear();
+          res.output_indices.clear();
+          res.status = Message::STATUS_FAILED;
+          res.error_details = "failed retrieving a requested block";


transaction

fair enough; I put block because it's in the get blocks rpc, but tx makes sense, context should be known.

moneromooo-monero · 2017-07-08T12:26:32Z

src/rpc/daemon_handler.cpp

+      for (const crypto::hash& h : bwt.block.tx_hashes)
+      {
+        bwt.transactions.emplace(h, *tx_it);
+        tx_it++;


Should still error out if tx_it goes to end()

moneromooo-monero · 2017-07-08T12:35:07Z

src/rpc/daemon_handler.cpp

+    res.info.grey_peerlist_size = m_p2p.get_peerlist_manager().get_gray_peers_count();
+
+    res.info.testnet = m_core.get_testnet();
+


This is missing various fields added in the last year

I'll go through all the calls to make sure they're up to date, and get rid of the deprecated ones.

moneromooo-monero · 2017-07-08T12:39:13Z

src/rpc/daemon_handler.cpp

+  {
+    res.status = Message::STATUS_FAILED;
+    res.error_details = "RPC method not yet implemented.";
+  }


I think all remnants of fast exit were nuked ages ago

I'll go through all the calls to make sure they're up to date, and get rid of the deprecated ones.

moneromooo-monero · 2017-07-08T12:41:18Z

src/rpc/daemon_handler.cpp

+
+  void DaemonHandler::handle(const GetRPCVersion::Request& req, GetRPCVersion::Response& res)
+  {
+    res.version = DAEMON_RPC_VERSION;


This should be renamed wiht 0MQ in the name or it'll get confused with the existing one (as I just did).

moneromooo-monero · 2017-07-08T12:46:16Z

src/rpc/message_data_structs.h

+    outputs_for_amount outputs;
+  };
+
+  struct peer


This needs to shed ip assumption, see the new network_address class

since the wallet doesn't use that RPC call, I hadn't touched it up yet. Will deal with that when I go through to check all the other calls I've implemented for changes.

moneromooo-monero · 2017-07-08T12:48:03Z

src/rpc/zmq_server.cpp

+
+  while (1)
+  {
+    if (rep_socket)


Looks like this will busy eat the CPU is rep_socket is false/NULL.

moneromooo-monero · 2017-07-08T12:49:18Z

src/rpc/zmq_server.cpp

+          zmq::message_t reply(response.size());
+          memcpy((void *) reply.data(), response.c_str(), response.size());
+
+          rep_socket->send(reply);


No error code ?

cpp bindings for zmq throw, catching now.

On that note, not sure if best course is to re-throw upon catching and error messaging, or silently ignore. Will have to research a little to see how resilient it is.

moneromooo-monero · 2017-07-08T12:50:22Z

src/rpc/zmq_server.cpp

+    std::string bind_address = addr_prefix + address + std::string(":") + port;
+    rep_socket->bind(bind_address.c_str());
+  }
+  catch (std::exception& e)


you missed one about 30 lines above that ;)

moneromooo-monero · 2017-07-08T12:52:06Z

src/serialization/json_object.cpp

+    throw WRONG_TYPE("integer");
+  }
+
+  if (val.GetInt() > 0xFF)


7f (and negative bound too at... -80 I think)

yeah, there's definitely a less clumsy but imo uglier way of doing this. Will sort it simply for now and look into a cleaner solution later.

I re-worked this logic in a PR issued to @tewinget repo/branch. The limits are now checked using numeric_limits<...>min/max.

Noted; reviewed on my repo.

ghost · 2017-07-10T22:15:37Z

Can't some of the more general fixes (e.g. to blockchain.cpp) be submitted as separate PRs, leaving only the ZMQ RPC stuff to go in?

tewinget · 2017-07-11T03:56:52Z

Unless I messed up, those changes are needed/relevant, or rather without them the new code would be less clean/dry.

…

On Jul 10, 2017 6:15 PM, "Nano Akron" ***@***.***> wrote: Can't some of the more general fixes (e.g. to blockchain.cpp) be submitted as separate PRs, leaving only the ZMQ RPC stuff to go in? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5nfxsMDP6t_G-VCGJ5k-uSF2VZxMks5sMqKMgaJpZM4NlTvc> .

moneromooo-monero · 2017-07-11T08:36:31Z

NanoAkron was not asking to remove them, but to PR them separately. Which is a good idea usually (at least commit them separately, which is what I try to do). With this particular massive patch set though, I think it's past the point where it can be made to look nice anyway. Let it be the last one to be ^_^, and let's get it merged once the missing recent (and not so recent) changes are also in the 0MQ RPC :)

tewinget · 2017-07-11T08:48:49Z

I see. It might not actually take more than a few minutes to restructure the commits in a way that supports PRing as such. I'm gonna knock out the rest for this PR today anyway, so I'll look into it. Taking longer than expected to clean things up; working on it though.

…

On Jul 11, 2017 4:36 AM, "moneromooo-monero" ***@***.***> wrote: NanoAkron was not asking to remove them, but to PR them separately. Which is a good idea usually (at least commit them separately, which is what I try to do). With this particular massive patch set though, I think it's past the point where it can be made to look nice anyway. Let it be the last one to be ^_^, and let's get it merged once the missing recent (and not so recent) changes are also in the 0MQ RPC :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5pfltmWHgzZCIvz2ssH6XAbIFud3ks5sMzQRgaJpZM4NlTvc> .

peronero · 2017-07-21T05:33:56Z

@fluffypony @luigi1111 @iamsmooth @moneromooo-monero

It's 3 weeks into the next month and 10 days since last message from @tewinget and this is still not merged.

I will not be here for the dev meeting but if not merged by then I strongly recommend that the community finds someone else to complete this work as per the 2nd option above - billing against the remaining funds from this FFS and disbursing the difference, if any, tewinget's way.

It's ridiculous that volunteers have to chase down what is effectively a $2000/hr developer to complete work that is more than half a year late.

ghost · 2017-07-23T17:33:04Z

Could you squash commits to remove things like 'macros, yay' please?

barnyardanimal · 2017-07-31T23:16:31Z

This would be a lot easier to review if broken into smaller pieces. Can we have another update from @tewinget on his effort to clean things up?

tewinget · 2017-08-01T01:07:22Z

Hmm...others have asked for me to make it bigger pieces, so to speak, i.e. to squash commits. Perhaps while squashing I can make each commit a clearly focused area of development. I'm not sure it will be nontrivial to do so, however. I'll take a look at it in a couple hours.

…

On Mon, Jul 31, 2017 at 7:16 PM, barnyardanimal ***@***.***> wrote: This would be a lot easier ton review if broken into smaller pieces. Can we have another update from @tewinget <https://github.com/tewinget> on his effort to clean things up? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5hEoG_htRhjS3CK7o_7RAWIQDhA9ks5sTmBSgaJpZM4NlTvc> .

-- Thomas Winget Computer Engineering Purdue University '12

moneromooo-monero · 2017-08-01T13:23:26Z

I think cleaning up commits helps a lot, because you then have N commits of size X, instead of one large amorphous blob of size N*X, because it can't really be considered small parts. That said, I'm ready to accept this PR as a large set of disparate commits, as long as it's the last one. But some cleanup would be most welcome (especially rolling any fixes/cleanups back into the commit which introduced them if that applies here).

tewinget · 2017-08-01T16:42:05Z

Yeah, I was working on doing precisely that last night when git complained about conflicts...I haven't used squash before and was nearly asleep at that point though, so I likely did it wrong. I'll squash properly in the next few hours. Edit: in light of vtnerd's PR on my repo, I may as well wait to squash until I incorporate those (necessary) changes, once they're merged. Will squash as soon as I merge those changes (once I'm comfortable with them), with attribution, of course.

…

On Aug 1, 2017 9:23 AM, "moneromooo-monero" ***@***.***> wrote: I think cleaning up commits helps a lot, because you then have N commits of size X, instead of one large amorphous blob of size N*X, because it can't really be considered small parts. That said, I'm ready to accept this PR as a large set of disparate commits, as long as it's the last one. But *some* cleanup would be most welcome (especially rolling any fixes/cleanups back into the commit which introduced them if that applies here). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5jCSMDm-aCnwNVvTPnw1VovEnFRBks5sTybQgaJpZM4NlTvc> .

expez · 2017-08-12T14:43:14Z

I would recommend either:

1 - getting committment from tewinget to complete this work on some sort of firm timetable
2 - having someone familiar with the codebase (like @moneromooo-monero ) estimate the remaining effort and reallocating the difference from the 1000XMR left to another developer

Two months ago we tried 1).

Would you be OK with giving 2) a try @tewinget?

tewinget · 2017-08-12T18:14:07Z

I'm currently waiting on feedback....

…

On Sat, Aug 12, 2017 at 10:43 AM, Lars Andersen ***@***.***> wrote: I would recommend either: 1 - getting committment from tewinget to complete this work on some sort of firm timetable 2 - having someone familiar with the codebase (like @moneromooo-monero <https://github.com/moneromooo-monero> ) estimate the remaining effort and reallocating the difference from the 1000XMR left to another developer Two months ago we tried 1). Would you be OK with giving 2) a try @tewinget <https://github.com/tewinget>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5rDYq80YGvLaE9_vT1eUY7es3CfWks5sXboEgaJpZM4NlTvc> .

-- Thomas Winget Computer Engineering Purdue University '12

dternyak · 2017-08-25T08:42:40Z

@tewinget It appears there are a few outstanding comments by @moneromooo-monero that have gone unaddressed.

Are you planning on addressing these?

tewinget · 2017-08-25T10:15:08Z

I'm fairly certain that I addressed all of the comments on this PR, though I have less confidence in whether or not I replied as much to each on here. Nevertheless, I'll go back through when I rebase later today.

…

On Aug 25, 2017 4:42 AM, "Daniel Ternyak" ***@***.***> wrote: @tewinget <https://github.com/tewinget> It appears there are a few outstanding comments by @moneromooo-monero <https://github.com/moneromooo-monero> that have gone unaddressed. Are you planning on addressing these? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5qxUls7aFuXGzVXRdmhUFLcAo0nTks5sbokDgaJpZM4NlTvc> .

dternyak · 2017-08-25T11:45:43Z

Great -- thank you.

ghost · 2017-09-03T23:37:28Z

It appears the last commit was about 10 weeks ago. Is this in a state to merge? The 1000XMR is now around a quarter of a million dollars...

tewinget · 2017-09-04T08:49:09Z

It should be, yes. The timestamp on the commit doesn't show rebasing and amending, oddly enough.

…

On Sun, Sep 3, 2017 at 7:37 PM, Nano Akron ***@***.***> wrote: It appears the last commit was about 10 weeks ago. Is this in a state to merge? The 1000XMR is now around a quarter of a million dollars... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5tTSbS8DzGvoPI0A_OPic4NLgESoks5sezg5gaJpZM4NlTvc> .

-- Thomas Winget Computer Engineering Purdue University '12

ghost · 2017-09-04T11:11:40Z

@tewinget Good to hear! Have you addressed all of @moneromooo-monero's concerns above though? There still seem to be 6 open discussions - would you at least comment on them so we can hear your thoughts?

tewinget · 2017-09-04T22:16:50Z

I believe so, but of course I forgot to write as much. I'll take care of it when I'm not on my phone.

…

On Sep 4, 2017 7:11 AM, "Nano Akron" ***@***.***> wrote: @tewinget <https://github.com/tewinget> Good to hear! Have you addressed all of @moneromooo-monero <https://github.com/moneromooo-monero>'s concerns above though? There still seem to be 6 open discussions - would you at least comment on them so we can see your thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5q7f_HjyVfpLmXCnKxdXYXc9lnb8ks5se9rvgaJpZM4NlTvc> .

This commit refactors some of the rpc-related functions in the Blockchain class to be more composable. This change was made in order to make implementing the new zmq rpc easier without trampling on the old rpc. New functions: Blockchain::get_num_mature_outputs Blockchain::get_random_outputs Blockchain::get_output_key Blockchain::get_output_key_mask_unlocked Blockchain::find_blockchain_supplement (overload) functions which previously had this functionality inline now call these functions as necessary.

Structured {de-,}serialization methods for (many new) types which are used for requests or responses in the RPC. New types include RPC requests and responses, and structs which compose types within those. # Conflicts: # src/cryptonote_core/blockchain.cpp

@vtnerd

- Add some RPC commands (and touch up a couple others) - some bounds checking - some better pointer management - const correctness and error handling -- Thanks @vtnerd for type help with serialization and CMake changes

tewinget · 2017-09-05T16:25:11Z

@NanoAkron thanks for reminding me I hadn't replied to those comments. I have now.

moneromooo-monero · 2017-09-07T13:58:11Z

I'd like this to be merged shortly after we are sure the release isn't borked.

fluffypony

Reviewed

0299cb7 Fix various oversights/bugs in ZMQ RPC server code (Thomas Winget) 7798602 json serialization for rpc-relevant monero types (Thomas Winget) 5c1e08f Refactor some things into more composable (smaller) functions (Thomas Winget) 9ac2ad0 DRY refactoring (Thomas Winget)

hyc · 2017-09-18T17:13:26Z

A few other problems with this PR. The code now depends on libzmq and a C++ wrapper for it <zmq.hpp> but there is no corresponding CMake test for this. Also this dependency needs to be listed in the README.md. As of now the build fails without explanation on various systems that don't have zmq installed by default. (E.g. #2471 )

danrmiller · 2017-09-19T03:57:13Z

Do these undefined references in libzmq.a when using the wrapper from https://github.com/zeromq/cppzmq pretty much mean the bindings don't match the libs in the packages? Or something else?

I'm sure lots of users would prefer to be able to use the libs packaged by their OS, so I hope that will end up working.

https://build.getmonero.org/builders/monero-static-dragonflybsd-amd64/builds/1346/steps/compile/logs/stdio
https://build.getmonero.org/builders/monero-static-ubuntu-amd64/builds/2328/steps/compile/logs/stdio
https://build.getmonero.org/builders/monero-static-win64/builds/2280/steps/compile/logs/stdio

tewinget · 2017-09-19T06:47:10Z

iirc the c++ bindings I chose to use come with libzmq (use newest) not cppzmq.

…

On Sep 18, 2017 11:57 PM, "Dan Miller" ***@***.***> wrote: Do these undefined references in libzmq.a when using the wrapper from https://github.com/zeromq/cppzmq pretty much mean the bindings don't match the libs in the packages? Or something else? I'm sure lots of users would prefer to be able to use the libs packaged by their OS, so I hope that will end up working. https://build.getmonero.org/builders/monero-static- dragonflybsd-amd64/builds/1346/steps/compile/logs/stdio https://build.getmonero.org/builders/monero-static-ubuntu- amd64/builds/2328/steps/compile/logs/stdio https://build.getmonero.org/builders/monero-static-win64/ builds/2280/steps/compile/logs/stdio — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2044 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE3k5p8bhAclrZZcpLcbIrudIY9___K8ks5sjzucgaJpZM4NlTvc> .

jtgrassie · 2017-09-20T20:30:43Z

Sorry but latest (4.2.2) does not seem to include the cpp bindings (as installed via MacPorts and Homebrew on OSX). For OSX you have to install cppzmq too.

Sexual · 2017-09-25T21:59:22Z

Does this also add support for ZMQ pub/sub such as bitcoin's zmqpubhashtx. I couldn't seem to find any references to it in the code, so I'm doubtful.

moneromooo-monero reviewed May 27, 2017

View reviewed changes

moneromooo-monero reviewed Jul 8, 2017

View reviewed changes

tewinget mentioned this pull request Jul 21, 2017

Daemon RPC Client (and wallet refactored to use new interface) #2185

Closed

DRY refactoring

9ac2ad0

tewinget added 3 commits September 5, 2017 12:17

Fix various oversights/bugs in ZMQ RPC server code

0299cb7

- Add some RPC commands (and touch up a couple others) - some bounds checking - some better pointer management - const correctness and error handling -- Thanks @vtnerd for type help with serialization and CMake changes

fluffypony approved these changes Sep 18, 2017

View reviewed changes

fluffypony merged commit 0299cb7 into monero-project:master Sep 18, 2017

danrmiller mentioned this pull request Sep 20, 2017

OS X build error #2497

Closed

		res.info.grey_peerlist_size = m_p2p.get_peerlist_manager().get_gray_peers_count();

		res.info.testnet = m_core.get_testnet();

Zmq RPC in daemon #2044

Zmq RPC in daemon #2044

Conversation

tewinget commented May 24, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fluffypony commented May 30, 2017

peronero commented Jun 10, 2017 • edited

tewinget commented Jun 10, 2017 via email

dternyak commented Jun 10, 2017

ghost commented Jun 10, 2017

peronero commented Jun 11, 2017

tewinget commented Jun 11, 2017 via email

tewinget commented Jun 25, 2017

peronero commented Jul 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost Jul 9, 2017 • edited by ghost

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tewinget Jul 10, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ghost commented Jul 10, 2017

tewinget commented Jul 11, 2017 via email

moneromooo-monero commented Jul 11, 2017

tewinget commented Jul 11, 2017 via email • edited

peronero commented Jul 21, 2017 • edited

ghost commented Jul 23, 2017

barnyardanimal commented Jul 31, 2017 • edited

tewinget commented Aug 1, 2017 via email

moneromooo-monero commented Aug 1, 2017

tewinget commented Aug 1, 2017 via email • edited

expez commented Aug 12, 2017

tewinget commented Aug 12, 2017 via email

dternyak commented Aug 25, 2017

tewinget commented Aug 25, 2017 via email

dternyak commented Aug 25, 2017

ghost commented Sep 3, 2017

tewinget commented Sep 4, 2017 via email

ghost commented Sep 4, 2017 • edited by ghost

tewinget commented Sep 4, 2017 via email

tewinget commented Sep 5, 2017

moneromooo-monero commented Sep 7, 2017

fluffypony left a comment

Choose a reason for hiding this comment

hyc commented Sep 18, 2017

danrmiller commented Sep 19, 2017

tewinget commented Sep 19, 2017 via email

jtgrassie commented Sep 20, 2017

Sexual commented Sep 25, 2017

tewinget commented May 24, 2017 •

edited

peronero commented Jun 10, 2017 •

edited

ghost Jul 9, 2017 •

edited by ghost

tewinget Jul 10, 2017 •

edited

tewinget commented Jul 11, 2017 via email •

edited

peronero commented Jul 21, 2017 •

edited

barnyardanimal commented Jul 31, 2017 •

edited

tewinget commented Aug 1, 2017 via email •

edited

ghost commented Sep 4, 2017 •

edited by ghost